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Abstract 

Improper use of Inter-Process Communication (IPC) within con- 
current systems often creates data races which can lead to bugs that 
are challenging to discover. Techniques that use Satisfiability Mod- 
ulo Theories (SMT) problems to symbolically model possible exe- 
cutions of concurrent software have recently been proposed for use 
in the formal verification of software. In this work we describe a 
new technique for modeling executions of concurrent software that 
use a message passing API called MCAPI. Our technique uses an 
execution trace to create an SMT problem that symbolically models 
all possible concurrent executions and follows the same sequence 
of conditional branch outcomes as the provided execution trace. 
We check if there exists a satisfying assignment to the SMT prob- 
lem with respect to specific safety properties. If such an assignment 
exists, it provides the conditions that lead to the violation of the 
property. We show how our method models behaviors of MCAPI 
applications that are ignored in previously published techniques. 

Categories and Subject Descriptors D.2.4 [Software Engineer- 
ing]: Software/Program Verification — Model checking 

General Terms Languages, Verification 

Keywords MCAPI, Symbolic Analysis, Multicore, SMT 

1. Introduction 

With the growing availability of multicore processors has come an 
increase in the amount and complexity of concurrent software. The 
non-deterministic interleaving of threads within a concurrent pro- 
gram can lead to bugs that are very difficult to discover. Misuse 
of Inter-Process Communication (IPC) within concurrent software 
creates data races that can then lead to errors within a system. Be- 
cause the manifestations of the data races depend on the whims of 
the operating system’s scheduler and delays in message transmis- 
sion, error states that are the result of data races can be very difficult 
to produce, reproduce, and identify with ad-hoc testing methods. 

Message passing is a form of IPC that involves defining message 
endpoints that provide different threads the ability to send data to 
specific endpoints. The Multicore Communications API (MCAPI) 
is a new message passing API that was released by an organization 
known as the Multicore Association [4]. MCAPI provides an inter- 
face designed for embedded systems that allows communication at 
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different system levels. For example, MCAPI can be implemented 
in both hardware and software so that an application running in a 
Linux environment can communicate directly with a graphics pro- 
cessing unit (GPU) and a digital signal processor (DSP). 

The semantics of message passing applications are difficult to 
model. Data non-determinism in message passing applications is 
expressed in instances where a single receive operation could re- 
ceive a message from any number of send operations. Which mes- 
sage is received depends on process scheduling and the length 
of delays in message transmission. The two previously proposed 
methods for formal MCAPI application verification do not cor- 
rectly model all the possible behaviors of MCAPI applications. 
This work specifically overcomes those limitations. 

MCC (MCAPI Checker) is a model checker specifically writ- 
ten to verify MCAPI applications [5]. Although MCC represents 
important progress in the verification of MCAPI applications, it ig- 
nores certain behaviors of MCAPI applications because it is not 
able to consider non-deterministic delays in the communication 
network when sending messages from two different threads to a 
common endpoint. Ignoring these behaviors prevents MCC from 
performing a complete verification of MCAPI applications. 

Wang et al. recently described an SMT-based model checking 
framework called Fusion [6], Fusion employs a property-driven 
reduction technique for the verification of concurrent applications 
that use shared memory. In a series of benchmark tests it was shown 
that Fusion had significantly shorter runtimes than a comparable 
tool. Inspect, that uses dynamic partial-order reduction (DPOR) 
[3. 7], The impressive results of Fusion were the inspiration for this 
work to generate SMT problems to model MCAPI applications. 

A very closely related work attempts to model MCAPI applica- 
tion executions as SMT problems [2]. To the best of our knowledge 
this work ignores potential delays in the MCAPI communication 
network. By ignoring these possible delays this work does not prop- 
erly model certain MCAPI application behaviors. As with MCC, by 
ignoring these possible behaviors the method defined in [2] cannot 
perform a complete verification of MCAPI applications. 

We have defined a new method for modeling MCAPI applica- 
tion executions as SMT problems in a manner that symbolically 
models all possible concurrent executions and follow the same se- 
quence of conditional branch outcomes as the provided execution 
trace. Our method captures all possible behaviors of the system, 
and it is much simpler than the method presented in [2]. We briefly 
describe our method in the following section. 

2. Modeling MCAPI Executions 

As an illustration we present an abstraction of a very simple 
MCAPI application in Figure 1. The send calls are used to send 
messages to specified threads. A thread can obtain the message 
by calling recv. When multiple threads send messages to a single 
endpoint no order of messages is guaranteed when the receiving 
thread calls the recv function. For example, since both send calls 
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(a) Possible send/recv Pairings. (b) Possible send/recv Pairings. 

Figure 1 : Simplified MCAPI program. 


Figure 4: Possible Pairings of send/recv calls from Figure 1. 


sending to thread t-o can occur before thread to is executed, either 
message could be received when thread to calls recv on line 1. 

The process of creating an SMT problem to model an MCAPI 
application execution is started by generating an arbitrary execution 
trace through the program and then analyzing the trace to generate a 
set of possible matching send operations for each receive operation 
in the trace. A pair of send and receive operations match when the 
receive operation receives the message that was sent by the send 
operation. We call this pair of operations a “match pair”. 


a specific send operation, and that each receive operation is paired 
with a different send operation. To assert this we use the algorithm 
in Figure 3. The results from the two algorithms are conjuncted 
with assertions on program order ( 7 Order ), negated properties that 
define a correct system (^7p r0 p), and other events in the execu- 
tion (tP Events)- The result is an SMT problem that models possible 
executions of an MCAPI application. 


7 ^ Order A 7 MatchPairs A 7 Unique A '7 p ro p A 7 Events 


1 : IP MatchPairs — tfUG 

2: for each recv G MatchPairs do 

3: tmp := false 

4: for each send G getSends( recv) do 

5: tmp := tmp V match (recv, send ) 

6: 7 MatchPairs •— 7 MatchPairs A ( t'lllp ) 

Figure 2: Match pair encoding algorithm. 

Our trace analysis generates a set MatchPairs that contains 
every receive operation in the trace, and it also provides a function 
getSends that maps each receive operation to the set of all the send 
operations that it could match with. This set and function are used 
in the simple algorithm shown in Figure 2 that encodes all possible 
match pairs in the execution trace being modeled. The inner loop 
of this algorithm constructs a disjunction, in the variable tmp, 
of all the send operations that a specific receive operation could 
pair with. The outer loop forms a conjunction of the disjunctions 
created for each of the receive operations in the trace. The result is 
a boolean representation of every possible match pair discovered 
in the trace analysis. The trace analysis also assigns each send 
operation a unique identifier for use in the SMT problem. Each 
receive operation is associated with an unbound identifier variable 
that an SMT solver will attempt to assign with the value of a single 
send operation's identifier. If such an assignment can occur, given 
the constraints of the problem, it signifies a match between the send 
and receive operations. 

1 . IP Unique — true 

2: for each recvi G {0 . . . \ Recvs\\ do 

3: for each recvj G {* + 1 . . . \Recvs\} do 

4: 7 Unique := 7 Unique A isDiffSend ( recVi , recvj) 

Figure 3: Uniqueness assertion algorithm. 

The match function on line 5 of Figure 2 is a simple function 
for use in the SMT model. Given a receive and a send operation 
the match function asserts that the call to send occurs before the 
call to receive, the message sent is the same message that is being 
received, and that the identifiers of the two operations are equal. 
MCAPI also provides a non-blocking receive operation along with 
a wait operation that blocks until the associated non-blocking call 
has completed. In the case of a non-blocking receive, the match 
function asserts that the call to send occurs before the call to the 
wait operation that is associated with the receive. Checking the 
identifiers assures that a specific receive operation is matched with 


The SMT problem can be solved by a constraint solver such as 
Yices [ 1 ] . As the system properties are negated, if the SMT problem 
is found to be satisfiable then a property violation is possible in the 
application under test. A simple analysis of the set of satisfying 
assignments provides a description of the path to the error state. 

As stated previously, the technique used in MCC does not con- 
sider non-deterministic delays that can occur when two messages 
are sent from different threads to a common endpoint. If applied 
to the scenario in Figure 1, MCC would only explore the behavior 
shown in Figure 4a. It would not consider that the message front 
send(Y) in thread t 2 could delay so long that the recv(A) operation 
would receive its message from send(X) in thread it. Besides pre- 
senting an unnecessarily complicated encoding method, the method 
presented in [2] also ignores the behavior represented in Figure 4b. 

3. Results and Future Work 

We have formally defined the semantics of a relevant subset of 
the MCAPI API in the Redex rewrite language. Based on these 
semantics we have created a tool that takes as input a trace, a set 
of match pairs, and a set of correctness properties. The output is 
an SMT problem that accurately models all possible executions of 
the trace. A precise set of match pairs can be generated through 
a depth-first abstract execution of the trace. Though precise, this 
method can be prohibitively expensive in computation time. As 
future work we plan to define a method for generating a reasonable 
over-approximation of the match-pair set, and to define a method 
for using the over-approximated set of match pairs to generate an 
SMT problem that models all possible behaviors of the trace. 
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